fix(docker): align generated S3 and metrics credentials - #105

Description

Fix credential mismatches present in v1.14.1 and main:

• Both Compose files reference S3_USER_* variables that gen-secrets.sh does not generate. Read S3_ACCESS_KEY_ID and S3_SECRET_ACCESS_KEY instead.
• Supply Data Service with S3_ACCESS_KEY and S3_SECRET_KEY, matching its application.yml. Metadata Service keeps its own expected environment names.
• Generate metrics.cnf with the same READONLY_PASSWORD used for database initialization, in both development and installer layouts.
• Keep default S3 credentials and storage initialization admin credentials unchanged.

Deployment evidence

These credential mismatches were encountered and corrected in our ITB Docker Compose deployment running v1.13.4. CSV upload returned HTTP 500 because SeaweedFS rejected the credentials used by Data Service.

After correcting both the Compose variable references and Data Service environment names, the application-consumed credentials matched SeaweedFS, and an authenticated S3 request returned HTTP 200.

The same mismatches remain in v1.14.1/main. This PR has configuration-level regression checks; live deployment testing of this branch remains pending.

Expected impact

Generated credentials reach Metadata Service, Data Service, and MySQL exporters consistently, instead of using default credentials that no longer match the generated configuration.

Type of Change

• Bug fix

Related Issue

Related deployment context: #97. This PR does not resolve the installer failures tracked there.

Validation

• python3 .scripts/test-compose-credentials.py — passed.
• bash -n .scripts/gen-secrets.sh — passed.
• git diff --check — passed.
• Confirmed the regression check fails when each of the three production-file fixes is reverted independently.

The regression check covers both Compose files, default and custom S3 credentials, admin credentials, and both metrics output paths. It uses Docker Compose configuration rendering without starting containers. Database configuration generation runs only in temporary directories; it does not rotate deployment secrets or run sudo.

Checklist

• My code follows the code style of this project.
• I have added tests to cover my changes.
• All new and existing tests passed.

Additional Notes

The full test suite and a live deployment smoke test have not been run. Installer, Valkey output-path, and exporter health-check fixes are outside this PR.

Existing deployments using S3_USER_* overrides must move those values to S3_ACCESS_KEY_ID and S3_SECRET_ACCESS_KEY. Do not rerun the entire secret generator on an existing deployment without coordinating credential rotation: persistent databases can retain their previous passwords.